Proposed by Carla Griggio (profile, biography) Don't forget to submit this proposal to official Google Melange site too!
How will I do that project
I'll guide my work through these main objectives:
- Keep the UML description model as much separated as possible from the graphic logic to keep it clean and simple. The user will describe an UML diagram through a defined protocol / interface / API, which I'll call the diagram code.
- Model the construction of graphics to be as simple as possible, oriented to create UML diagrams (thinking about nodes, connectors or relations, labels, positioning, etc.) but without coupling it to the UML description model.
- Prioritize building the diagrams programatically (using the diagram code) over getting them from a project's source code automatically. The main objective of the project should be describing an UML diagram illustrating a situation and getting a graphic diagram matching that description. Automatically generated diagrams should be just suggestions on what the diagram may look like, but the user must be able to adjust it upon what he really means to communicate in it.
- In order to be useful to the community, it has to be easy to use it.
- The diagram code must be intuitive and declarative.
- The tools that give access to make autogenerated suggested diagrams should be easy to find and to use (i.e.: menu options when right-clicking on a Package or a Class or even a piece of code, special windows/browsers that help building and visualizing diagrams, etc).
- The website should be very very clean, with few functionalities. There should be help pages explaining how to write the diagram code.
More detailed aspects:
The project will be used under two different scenarios:
- Through the website
- Within the Pharo IDE
I'm going to use Morphic for generating the diagrams graphics. The morphs will be useful for both IDE and website needs, as I can export them to JPEG / PNG or other image formats for the web easily.
When building diagrams in Pharo, the morphs could be modified by GUI tools instead of being modified programmatically (although using the diagram code will always be an option).
I've been looking at some drawing projects like Mondrian, GraphViz and Connectors. I will take ideas from them (and maybe others) to make an 'UML graphics builder core' specially for this project (so it gets to be as simple as it needs to and no more than that, and besides, the project gets to be independent of other developments), although I consider porting Connectors to Pharo as an option if after studying it I see that it's convenient (I wouldn't use Mondrian to avoid depending on a big framework, and GraphViz would kill the projects portabillity).
I'll implement the website with Seaside as suggested in the project's description. The code typed in the website for getting a diagram graphic should be restricted to the diagram code only. It would be great to include some already made examples in the website as part of the documentation.
I plan to give a lot of thinking to the design of the diagram code. It's really important that the diagram code gets to be usefull fordescribing an UML diagram (or better yet, the design ideas that get illustrated with UML diagrams).
The autogeneration of diagrams needs to be done using 'reflection' or in other words, looking at the meta model.
What methodologies will I use
Once I have a general idea of the general design of the project, I'd love to do Test Driven Development concentrating on one milestone at a time (see the milestones in the next section), what implies thinking of little tasks and writing lots of tests. I think that, particularly in this project, writing tests for the diagram building will help to achieve a nice API for doing that.
Suggested timeline and milestones
This timeline and milestones are based on the priorities I'm suggesting, though they may vary if the project's scope changes (more about that in the next section).
From April 27th to May 24th there's a Community Bonding period in the GSoC's program timeline. I'll use that time to read documentation useful for later coding, study the drawing frameworks named above and do some little experiments to start learning about Morphic and reflection.
Later milestones:
- A diagram code well defined that can be used to build UML description objects (that imples having the UML model working and tested). This implies developing the UML description model too.
Estimated date: 07/06
- The UML graphics builder core using Morphic
Estimated date: 01/07
- Geting an UML description to draw it's graphic diagram.
Estimated date: 08/07
- The website, where UML descriptions can be written in order to get the related diagrams.
Estimated date: 15/07 (ready for Mid-term evaluations)
In the remaining time until the final deadline I would go for the following milestones:
- Get autogenerated class diagrams suggestions of a package or a class hierarchy.
- (If there's still time) get autogenerated sequence diagrams suggestions from a block evaluation.
Where I see the risks
The whole project is big, so the main risk I see is not completing all the requirements within the given time. To consider this a successful project I would consult the mentors what would be a safe scope, and concentrate on achieving the functionalities within.
Of course I would like to keep working on the project after GSoC's deadline, even adding some functionalities that haven't been proposed in the current description.
The risks that I find that are more related to the project's requirements are related to the sequence diagrams generated from the evaluation of a block (although I've already been investigating about that) and the construction of good tools to build the graphics. These might be the most difficult aspects of the project and I'll have to learn about them during the development period.
How the results will look like
Well, I've made some prototypes for the website. They illustrate just the general idea, nothing definitive. As I mentioned before, I want the website to look very very simple.
Screen A:
Screen B:
As regards the code, I expect to get a clear and simple design. I want every aspect of the project to be well distinguished from each other, so each of them stays simple and extensible (it would be nice to add more kinds of diagrams later, maybe several drawing strategies, etc.)
|